数据 | 核心生产要素[1]数据工程05.平台与服务[6]平台运维

data

2025-10-27

Flink运维记录

Catalogue

1. 一、下载安装
2. 二、k8s部署模式
   1. 2.1 部署方式比较
   2. 2.2 Operator 实现原理
      1. 2.2.1 核心组件
   3. 2.3 生产级完整流程
      1. 2.3.1 前置条件
      2. 2.3.2 创建 Session 集群（FlinkDeployment）
      3. 2.3.3 提交作业到 Session 集群（FlinkSessionJob）
      4. 2.3.4 状态管理（FlinkStateSnapshot，可选）
      5. 2.3.5 运行时管控（HA / 自动扩缩容 / Savepoint）
      6. 2.3.5 自动扩缩容（集群级）
      7. 2.3.6 Savepoint 管理（作业级）
   4. 2.4 相关问题
      1. 2.4.1 TM 的Pod故障恢复
      2. 2.4.2 Application 模式的作业HA
   5. 2.5 生产选型建议（HA 视角）

一、下载安装

https://archive.apache.org/dist/flink/flink-1.12.2/

scala 2.12
https://www.scala-lang.org/download/2.12.15.html

二、k8s部署模式

2.1 部署方式比较

Flink on Kubernetes 提交方式对比

方式	资源隔离性	自动化程度	生产适用性	所需技术栈	优势场景
Native Session Mode	中	中	★★★★☆	K8s	简单快速）快速启动，适合共享集群
Native Application Mode	高	高	★★★★★	K8s + Docker	资源完全隔离，适合多团队协作
Kubernetes Operator	极高	极高	★★★★★	K8s + CRD + Helm	生产级 HA、Savepoint、自动扩缩容
Airflow/Argo Integration	高	高	★★★☆☆	Airflow + K8s	Airflow + 原生 K8s 模式:复杂工作流调度

2.2 Operator 实现原理

「Flink Kubernetes Operator 实现原理」
Flink Kubernetes Operator 本质上是一个 自定义控制器（Custom Controller），它通过 Kubernetes 的 CRD（Custom Resource Definition） 扩展原生 API，实现 Flink 集群和作业的自动化管理。以下是其核心组件和实现逻辑：

Operator 可以创建不同的 flink集群。 但生产 推荐 Session模式（支持作业级HA，资源复用 + 作业解耦，实现生产级的精细化运维）

2.2.1 核心组件

CRD（自定义资源）、控制器（Controller）、Webhook（可选）

（1）CRD（自定义资源）

FlinkDeployment：管理 长期运行的 Flink 集群（Session 模式）。
FlinkSessionJob：向 FlinkDeployment 提交具体作业（类比 JobGraph）。
FlinkStateSnapshot（可选）：保存 Savepoint/Checkpoint 状态（状态管理）。

（2）控制器（Controller）
监听 CRD 变化，触发调和循环 管理集群生命周期（创建/更新/删除）。

2.3 生产级完整流程

基于 Kubernetes Operator 实现（生产级部署方式），
FlinkDeployment（Session 集群） + FlinkSessionJob（作业提交） + FlinkStateSnapshot（状态管理）的组合模式

2.3.1 前置条件

集群侧：部署 Flink K8s Operator（1.18 + 推荐），注册FlinkDeployment/FlinkSessionJob/FlinkStateSnapshot CRD；
存储侧：配置共享存储（S3/HDFS）用于 HA 元数据、Checkpoint/Savepoint 存储；
权限侧：为 Operator 配置 RBAC 权限（允许关联FlinkDeployment与FlinkSessionJob）；
集群侧：提前规划 Session 集群资源（如 TM 数量、slot 数），满足多作业复用需求。

2.3.2 创建 Session 集群（FlinkDeployment）

创建长期运行的 Session 集群，仅负责集群管控，不提交作业：
通过 flink-session-cluster.yaml (FlinkDeployment) 实现

（自定义 JM、TM的内存：例如 5个Pod （1个 JM、4个TM））

提交并启动Session集群：

kubectl apply -f flink-session-cluster.yaml

「Operator 执行逻辑」

触发 Reconcile 循环，创建 Session 集群的 K8s 资源（JM Deployment、TM StatefulSet、Service、ConfigMap）；
启动 JM/TM Pod，初始化 HA 服务（连接 K8s API 存储集群元数据）；
集群启动后，Operator 更新FlinkDeployment状态。

核心特性：
资源复用：多FlinkSessionJob可共享同一个FlinkDeployment的 TM slot；
作业隔离：每个作业有独立的 Checkpoint/Savepoint 路径，互不干扰；
作业级 HA：作业失败时，Operator 按restartPolicy自动重启，无需重启整个 Session 集群。

2.3.3 提交作业到 Session 集群（FlinkSessionJob）

创建FlinkSessionJob，绑定到上述 Session 集群，提交具体作业（支持多作业并行提交）：
flink-session-job-1.yaml (FlinkSessionJob)

Operator 执行逻辑：
校验deploymentName是否存在且状态为 RUNNING；
通过 Session 集群 JM 的 REST API（/jars/upload + /jobs/run）提交作业；
作业启动后，Operator 更新FlinkSessionJob状态

2.3.4 状态管理（FlinkStateSnapshot，可选）

创建FlinkStateSnapshot，独立管理作业的 Savepoint/Checkpoint 元数据（简化状态恢复、版本管理）：
通过 flink-state-snapshot.yaml (FlinkStateSnapshot) 实现

提交后，Operator 会校验快照路径的有效性，并维护快照状态（如是否可用、关联作业是否运行）。

2.3.5 运行时管控（HA / 自动扩缩容 / Savepoint）

「集群级 HA（FlinkDeployment）」

• JM 故障：Session 集群 JM Pod 异常时，K8s 重启 JM；新 JM 从 HA 存储（high-availability.storageDir）读取集群元数据，恢复 TM 连接，已提交的作业自动续跑；
• TM 故障：StatefulSet 自动重启 TM，Operator 触发 Reconcile，确保 TM 副本数与FlinkDeployment配置一致；作业会自动将任务迁移到其他可用 TM slot。

「作业级 HA（FlinkSessionJob）」

• 作业失败：Operator 按restartPolicy自动重启作业，从最近的 Checkpoint/Savepoint 恢复（优先使用FlinkStateSnapshot关联的快照）；
• 作业隔离：单个作业失败不影响 Session 集群内其他作业运行。

2.3.5 自动扩缩容（集群级）

「可行性分析，需要机器资源管控考虑资源超用问题」
触发条件：Session 集群 TM 的 CPU 利用率超过 75%（horizontalPodAutoscaler配置）；
执行流程：
K8s HPA 修改FlinkDeployment的 TM 副本数（如从 8→12）；
Operator 感知到副本数变化，触发 Reconcile；
创建新 TM Pod，注册到 JM 后，集群总 slot 数增加（从 32→48）；
Operator 更新FlinkDeployment状态，已运行的作业可按需调整并行度（修改FlinkSessionJob的parallelism）。

2.3.6 Savepoint 管理（作业级）

手动触发：修改FlinkSessionJob的savepointTrigger：
Operator 触发 Savepoint 后，自动更新FlinkSessionJob状态，并可关联到FlinkStateSnapshot；

快照复用：新作业可直接引用FlinkStateSnapshot的快照路径，实现快速恢复：

2.4 相关问题

2.4.1 TM 的Pod故障恢复

那如果 TM 的Pod被移除了，集群级 HA 会怎么做？ 作业级 HA 的重启策略生效吗？
「 TM Pod 被移除（如节点宕机、K8s 驱逐、手动删除）时」

Pod失联导致作业FAILED

• 同时依赖集群的HA和作业的HA。

2.4.2 Application 模式的作业HA

在 Flink Kubernetes Operator 的Application 模式下作业级（业务级）HA 的重启策略（如ON_FAILURE/NEVER/nostart）依然核心生效，且逻辑与 Session 模式一致 —— 但因 Application 模式 “作业与集群强绑定” 的特性，重启策略的执行链路、触发场景与 Session 模式存在关键差异，最终仍是保障作业连续性的核心机制。

2.5 生产选型建议（HA 视角）

场景	推荐模式	HA 核心优势
长期运行的核心流式作业（如实时数仓、风控计算）	Application 模式	隔离性极强，HA 逻辑简单，故障影响面最小，运维成本低
批量短作业 / 多小作业（如定时 ETL、日志处理）	Session 模式	资源利用率高，作业故障隔离，重启成本低（无需重建集群）
作业并行度高、资源需求稳定	Application 模式	专属资源保障 HA 稳定性，避免共享资源竞争导致的恢复失败
作业数量多、资源需求波动大	Session 模式	集群级 HA 保障资源池稳定，作业级 HA 适配不同作业的恢复策略
核心敏感作业（如资金结算）	Application 模式 + nostart策略	隔离性 + 禁用自动重启，避免误恢复导致数据风险
非核心作业（如日志采集）	Session 模式 + ON_FAILURE策略	资源复用 + 自动恢复，降低运维成本

Session 模式的核心优势之一就是 “集群与作业解耦”。 在集群配置不变的前提下，迭代上线作业时完全无需重启 Session 集群，仅需更新FlinkSessionJob（或重新提交作业）即可完成上线。

关键边界：哪些场景仍需重启 Session 集群？